kick travis

Could you please rebase ?

Coverage remained the same at 58.344% when pulling 68e53de on typeless:add-unlock-notify into c67b489 on mattn:master.

I'd like to add a test for what the PR tries to fix but cannot deliver it in the first few attempts. I'll try later when I have more free time.

@typeless Could you rebase

@gjrtimmer Done

I wonder this can be tested.

@mattn I think you are right we need some code to test it, maybe even an example.

@typeless Instead of currently trying to write a test for it, You did probably design this with some code to see if it worked. Could you add an example for this to the _example folder ?

I notice that in the step function, you check the extended error code to make sure it's SQLITE_LOCKED_SHAREDCACHE, but you don't do this in the prepare code. Why not?

@bvinc It was modified from the example code: https://sqlite.org/unlock_notify.html

The explanation of the SQLITE_LOCKED_SHAREDCACHE check is described in the last few paragraphs.
It seems to me that sqlite3_blocking_prepare_v2 would not result in the same scenario as qlite3_blocking_step does.

By the way, I have found a test which can reproduce the "database is locked" error but it turned out that the PR does not fix the problem. I'll try to figure it out later and see if this PR has any hope to be helpful.

Which test can still reproduce "database is locked" error with this PR?

I found your test case in a closed PR. I assume this is the test case that you're talking about. I believe that there is some confusion again between SQLITE_BUSY and SQLITE_LOCKED.

Without using shared cache mode (which applies to your test), when two transactions conflict, the one that fails uses the busy handler, which waits a small number of random milliseconds, and then tries again. Once this fails for 5 seconds (which is the default busy timeout for this driver), then it fails with SQLITE_BUSY, which says database is locked. What's happening with your test case is that one statement is spinning so fast that it's completely starving out the other statement for a full 5 seconds. This is completely normal and just how SQLite works. You can see that if you increase the busy timeout by adding "?_busy_timeout=60000" that it won't give an error anymore.

But this PR is about something completely different. This PR is about stopping people from getting SQLITE_LOCKED when using shared cache mode (which your test case did not use).

@bvinc You're correct I misunderstood the two different errors. I need to try it again when I come back to this.

@mattn @gjrtimmer @bvinc The test has been added. PTAL.

Hmmm, I have to make it compatible with USE_LIBSQLUTE3 .

A new build tag sqlite_unlock_notify has been introduced.

Found a bug while trying to integrate the change into Gitea. I am looking into it.

Found a bug while trying to integrate the change into Gitea. I am looking into it.

The bugs have been figured out. For now, all available tests pass.

Thank you. Sounds good to me. One thing. please add _ for the functions always to be not use same namespace sqlite_.

@mattn Done. Is that what you mean?

Yes! Thank you.